Add control via KConfig of CAN_CONFIG.SWAP_ENDIAN bit for Microchip Polarfire CAN driver #96938
Conversation
Add a CAN driver for Microchip's PolarFire SoC platform. Signed-off-by: Sebastian Huber <[email protected]>
|
Hello @DonBrus, and thank you very much for your first pull request to the Zephyr project! |
zephyrbot
added
area: RISCV
zephyrbot
requested review from
albertofloyd,
alexanderwachter,
edersondisouza,
fkokosinski,
henrikbrixandersen,
jvasanth1,
katsuster,
kgugala,
martinjaeger,
mgielda,
npitre,
str4t0m,
tgorochowik,
VenkatKotakonda and
ycsin
…DIAN bit Default implementation of CAN driver for the Polarfire SoC inverts the byte ordering to write registers/from read registers due to platform endianness, possibly resulting in an unexpected behavior when considering the normal API usage of CAN. This adds KConfig support for forcing a configuration bit to be set, which will take care of reversing the byte order in hardware. Signed-off-by: Donato Brusamento <[email protected]>
DonBrus
force-pushed
the
can-mchp-mss-endian-swap
branch
from
d2beb85 to
df636d3
Compare
|
There was a problem hiding this comment.
The Polarfire SoC from Microchip allows a configuration of the CAN peripherals, via the SWAP_ENDIAN bit (13) of the respective CONFIG registers, that inverts the byte ordering for transmit and receive buffers.
This can be used to allow a more predictable usage of the peripheral, as the driver implementation on which this PR is based off will cause the bytes to appear on the bus possibly in inverted order with respect to expected behavior. For example, the usage example outlined in the CAN API will result in bytes appearing on the bus in the following sequence:
0x04 0x03 0x02 0x01 0x08 0x07 0x06 0x05, which does not reflect the ordering of the input buffer. By toggling the SWAP_ENDIAN bit, the sequence will be fixed(0x01 0x02 .. 0x05 0x06 ..)
The sent bytes must match the order in the buffer being sent, otherwise the driver breaks the CAN controller API contract. Introducing a Kconfig for this is not the right way to solve an issue like this.
Note: this PR cherry picks the commit proposed in #95698, which adds the CAN driver in the first place.
Please add you comments regarding byte order to that PR instead.
|
@henrikbrixandersen Thanks, I will have a look at this. |
The Polarfire SoC from Microchip allows a configuration of the CAN peripherals, via the SWAP_ENDIAN bit (13) of the respective CONFIG registers, that inverts the byte ordering for transmit and receive buffers.
This can be used to allow a more predictable usage of the peripheral, as the driver implementation on which this PR is based off will cause the bytes to appear on the bus possibly in inverted order with respect to expected behavior.
For example, the usage example outlined in the CAN API will result in bytes appearing on the bus in the following sequence:
0x04 0x03 0x02 0x01 0x08 0x07 0x06 0x05, which does not reflect the ordering of the input buffer. By toggling the SWAP_ENDIAN bit, the sequence will be fixed(0x01 0x02 .. 0x05 0x06 ..)Note: this PR cherry picks the commit proposed in #95698, which adds the CAN driver in the first place.